IBIS Macromodel Task Group Meeting date: 01 October 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Randy Wolff took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Walter to draft a new revision of BIRD197.5 with DC_Offset defined only as an In parameter. - Done - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. Randy commented that he talked internally with some engineers that represent Micron in JEDEC. They confirmed that the JEDEC specification does not include any details of DDR5 DQ equalization training. It is not discussed in the JEDEC meetings, as the controller vendors consider training to be their secret sauce. They recommended discussing training algorithms with companies such as Synopsys or Cadence that sell their DDR5 PHY IP to other companies making controllers. Michael commented that he is preparing some public-ready comments. If the standard specifies the protocol, how much needs to be standardized to define the protocol? Arpad added, how much needs to be specified without revealing sensitive information? Ambrish noted that defining BCI protocol originally was difficult, even with public specifications available for SerDes protocols. You could allow methodology to work assuming two models come from the same vendor or closely working vendors. At least provide that functionality in the first phase. Work on more complex protocols second. That's where BCI went first in the SerDes era. We should approach this the same way. Wei-hsing noted that most likely Tx and Rx were from the same vendor before. Ambrish added that there could be agreement between two companies under NDA. Wei-hsing commented that data can be exchanged without touching the IBIS specification. Ambrish added that we are still looking at first steps. Walter noted that Fangyi started introducing alternative ways of doing optimization done by the EDA tool. Walter has a couple slides to show how to discuss the terms about who owns what. Fangyi added that he also has two short slides to elaborate on previous ideas. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 24 meeting. Walter moved to approve the minutes. Michael seconded the motion. There were no objections. ------------- New Discussion: BIRD181.2: Deferred, as Mike L. was not in attendance. DC_Offst BIRD: Walter moved to untable BIRD197.5 for discussion. Michael seconded the motion. There were no objections. Walter shared the document bird197.5-1.docx, modified from the version that was sent to the reflector last week. Walter showed two sentences added by request from Ambrish as well as another sentence from Walter about the high/low threshold of Rx AMI_GetWave output waveform being returned by the AMI model being zero volts. Under Other Notes, Walter added a sentence from Ambrish about post processing data. Fangyi said we need to define post processing or what is being done by the EDA tool. Walter added language about comparing the waveform output of the Rx AMI_GetWave to the input waveform without the DC_Offset subtracted. Ambrish noted he wanted the sentence added to be clear about the usage of DC_Offset by the EDA tool. Fangyi noted he did not object to the sentence about the output waveform being nominally centered around zero volts. Fangyi asked why the second sentence was necessary regarding the EDA tool displaying the results. Ambrish noted post processing was mentioned in the specification in multiple places. Wei-hsing noted this sentence seems tool specific. Fangyi didn't think the sentence needed to be in the specification, since it was only related to displaying waveforms in the EDA tool. Arpad shared the IBIS 7.0 specification to show the use of "post process". Walter suggested changing "will use" to "may use" in the sentence. Ambrish thought adding an example to the BIRD would be a good idea. Ambrish will look into adding an example [AR]. Randy noted seeing some instances of "post-process" versus "post process" in the specification. Arpad suggested this get added to the IBIS 7.0 known issues document. Randy will take care of that [AR]. Radek asked about the Usage of the DC_Offset parameter. Walter confirmed the change was from InOut to In. Radek noted we should add some language about the parameter being applied to NRZ signaling, and not PAM4. Enabling Back-channel in Statistical Mode: Walter shared a presentation DDR5_DQ_Write_Protocol_Overview.pptx. He explained the training methodology. The Rx_Read pass-through block reads the BCI file, processes the waveform, generates an eye metric, then sends data back to the Tx through the BCI file. Then, the Tx gets called, going through the Tx_Read block, reading what the Rx has written. It may modify FFE taps or tell the Rx to do something different. The Tx writes out info for the Rx, and it iterates around. That's the way BIRD147 works in time domain. The statistical training method processes an impulse response instead of a waveform. In the case of DDR5 hardware, all the logic is done in the Tx. The controller vendor could create a tool with the IP in it. If we want the EDA vendor to write the process, it loses the IP of the controller vendor. Some questions include: Who owns the training algorithm? How is the eye metric calculated? Where does the DDR5 controller vendor want the training algorithm to reside? Michael noted two items missing as the owner. One thing to keep in mind is the EDA tool user may be a fourth owner. The silicon vendor has an idea about the right algorithm. So does the Rx designer. The system designer might have a third idea. This could be hard to implement. Also, the firmware may be a large part of this, and it could be from the controller vendor, or optimized by the owner of the system. You want the equalization training to happen as early as possible in the system power up. Walter noted the different blocks in the training have different expertise in creating them. The Tx_Read pass through block could be written in multiple languages. You'd like your code in that block to automatically generate the firmware code. Fangyi shared his slides Training_flow_comparison.pptx. He showed two training flows side by side, one proposed by Walter, and another based on current statistical simulation. Walter confirmed the flow was correct for his proposed flow. Fangyi stated that the EDA tool adjusts Tx/Rx equalization, then does the statistical eye calculation at the end of the AMI_Init flows. Basic steps are similar, but calculations happen differently. Michael asked if the arrows designate a required sequence in time. If it is truly LTI, the order shouldn't matter. Fangyi noted that there is a flow sequence defined in the spec. Walter said Michael was technically correct on the right side diagram if all the impulse processing was done correctly. Fangyi said almost true, except if Rx has DFE, you probably want to use Rx AMI_Init after Tx AMI_Init, since the DFE is added to the impulse response. Michael was trying to make sure we weren't smuggling assumptions into the flow. Fangyi showed another training flow based on current statistical simulation. The Rx could optimize EQ before modifying the impulse response in Rx AMI_Init. Walter noted the two alternatives are perfectly fine. They could run faster. Put yourself in the situation of being the memory vendor and controller vendor. The memory vendor has to generate an Rx that optimizes itself. The EDA tool, with control loops in the EDA tool, will have to know the AMI parameters for each controller model and memory model. If you can get all the memory vendors to use the same parameters, you might be ok. Every controller could have different parameters for different taps and granularity. Each simulator could come up with an answer, but the user wants what will actually be implemented in training. If the user wants the answer coming from the algorithm that the controller vendor is using, than the existing flows won't work. Arpad said he could see both flows being used. Some AMI model makers may not want to get into writing a training algorithm. Others may want to write their own algorithm because they think they are smarter. Walter noted the EDA tools already implement the existing training flows. The protocol could also work for when the Rx controls the optimization, but that is a much more difficult problem. There are a lot of people that want to do optimization in the statistical flows for performance reasons. Fangyi noted we should not forget the training could happen on the entire interface. The VGA Walter mentioned could amplify the crosstalk noise. Walter noted a lot of things could affect training. There are a certain number of DFE and FFE taps. The time constant for the channel is relatively short. The equalization values may be insensitive to crosstalk. There may be a tendency to train channels to minimize crosstalk. These are details we need to understand. Arpad said we are going to have to decide in the next meeting which of these flows we want in the BIRD. AR: Ambrish to look into adding graphic or improved example to BIRD197.5. AR: Randy to add "post-process" versus "post process" to the IBIS 7.0 known issues document. ------------- Next meeting: 8 October 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives